當(dāng)問到嵌入式程序員使用的是哪些工具時(shí)，往往將會(huì)發(fā)現(xiàn)他們有一個(gè)共同的思路：即C/C  、一種集成開發(fā)環(huán)境(IDE)或他們各自喜愛的編輯器/調(diào)試器以及一個(gè)標(biāo)準(zhǔn)庫或類似Microsoft .NET那樣的平臺(tái)。 嵌入式開發(fā)工具 1. 腳本語言 在嵌入式應(yīng)用中，程序員常常會(huì)忽視腳本語言。一般情況下，它們無法達(dá)到C語言的速度并且它們的運(yùn)行時(shí)框架很大。對于具有強(qiáng)大處理能力、大容量內(nèi)存及硬盤的PC來說，這些問題都不會(huì)造成影響。但在嵌入式環(huán)境中，上述問題卻將有可能產(chǎn)生制約。盡管該環(huán)境中的處理能力和存儲(chǔ)器容量仍在不斷增長，尤其是低成本32位MCU也開始出現(xiàn)。 對大部分腳本系統(tǒng)來說，基本代碼的規(guī)模是一個(gè)典型問題，因?yàn)樵擃愊到y(tǒng)通常被賦予豐富的特MOD。在某些情況下，可以將系統(tǒng)簡化為其最小的組件集，這樣，開發(fā)者就只需為他們所需要的特MOD承擔(dān)空間成本。這與開發(fā)者如何在C語言應(yīng)用中去除實(shí)時(shí)操作系統(tǒng)和運(yùn)行時(shí)間庫的狀況類似。此外，由于一般在運(yùn)行時(shí)處理繁重任務(wù)，因此最終生成的應(yīng)用程序通常較小。 腳本語言具有許多優(yōu)勢，例如，更靈活的類型系統(tǒng)和更好的文本處理功能，這些都將使某些應(yīng)用獲益。用它快速編寫簡單應(yīng)用的代碼也很容易，并且可能比C語言代碼更易移植。由于某些語言支持運(yùn)行時(shí)編譯，代碼也往往更具動(dòng)態(tài)特MOD。這不僅便于調(diào)試，而且還有助于設(shè)備實(shí)現(xiàn)更大的靈活MOD或更易定制化。 此外，腳本語言易于獲取且能得到很好的支持。Perl、PHP、Python、Ruby、TCL和Javascript被用于從網(wǎng)絡(luò)服務(wù)到服務(wù)器管理等一系列應(yīng)用中。當(dāng)然，對嵌入式應(yīng)用來說，基于Web的解決方案會(huì)導(dǎo)致一些有趣的折衷。 例如，許多嵌入式網(wǎng)絡(luò)設(shè)備可實(shí)現(xiàn)一個(gè)Web服務(wù)器并生成HTML頁面，可利用一個(gè)運(yùn)蠱OD詬嘰鞰OD能PC上的Web瀏覽器來瀏覽這些頁面。如果該P(yáng)C可用來處理通常由嵌入式設(shè)備負(fù)責(zé)的事務(wù)，那么會(huì)出現(xiàn)哪些情況呢？ 2. AJAX技術(shù) 這可以通過多種途徑來解決。一種正日益通用的方法是采用AJAX(異步JavaScript和XML)技術(shù)。在這種情況下，一臺(tái)嵌入式設(shè)備將通過其Web服務(wù)器提供信息和可能的Javascript代碼。這些代碼運(yùn)蠱OD赑C上，然后該P(yáng)C與采用XML格式消息的嵌入式設(shè)備進(jìn)行交互，以取代讓嵌入式設(shè)備生成完整HTML頁面的方法。 該方法不僅更具動(dòng)態(tài)MOD，而且由于是采用PC而非嵌入式設(shè)備(通常嵌入式設(shè)備的處理能力較低)來處理用戶間的交互，因此也顯著提高了響應(yīng)MOD能。與不采用該方法時(shí)類似，數(shù)據(jù)源是嵌入式設(shè)備，但Javascript程序可來自任何地方：服務(wù)器、網(wǎng)關(guān)或PC本身都有可能。對負(fù)載進(jìn)行分配和簡化嵌入式設(shè)備是個(gè)有趣的過程。無需修改嵌入式設(shè)備就可以構(gòu)造一個(gè)全新的用戶接口。 考慮是選擇腳本語言還是選擇AJAX是重要的一步。幸運(yùn)地是，許多腳本系統(tǒng)是以開放源碼的形式提供，從而可方便地實(shí)施評估。而諸如Javascript這樣的語言，在類似Web瀏覽器和服務(wù)器等應(yīng)用中已經(jīng)成為標(biāo)準(zhǔn)語言。 那些更大膽的開發(fā)者也許會(huì)考慮采用非主流語言(例如Lisp的變種Scheme語言)。許多Scheme平臺(tái)(例如Per Bothner公司的Kawa Scheme)可生成Java字節(jié)碼，從而使它們成為可與Java應(yīng)用共存的腳本系統(tǒng)。 嵌入式編程語言的最新動(dòng)向 Cremains是目前最流行的嵌入式編程語言，并且數(shù)年來一直獨(dú)占鰲頭。盡管如此，程序員的工具包還應(yīng)該更豐富一些，尤其是在處理諸如最新和改進(jìn)的互聯(lián)網(wǎng)以及異構(gòu)和多核系統(tǒng)的時(shí)候。工具包內(nèi)的選項(xiàng)可能是腳本語言、并行編程及圖形編程。 腳本語言源于PC和服務(wù)器，但它們同樣可應(yīng)用于嵌入式系統(tǒng)。對具有處理腳本系統(tǒng)所需存儲(chǔ)能力的32位系統(tǒng)來說尤其如此。 此外，腳本語言通常比C語言更具靈活MOD，這使其可以更加容易地用于一個(gè)應(yīng)用的各個(gè)部分。而像Perl、PHP、 Python和Javascript這樣的腳本語言通常可作為C語言的補(bǔ)充，并且它們常?；ハ嘤绊?，所以對兩類語言都有所了解是有好處的。 而且，腳本語言已經(jīng)被用于大型企業(yè)應(yīng)用的服務(wù)器端。這些應(yīng)用常常被分散在多個(gè)服務(wù)器中完成，但每個(gè)部分往往都相對獨(dú)立，因此，可將它們隨意地分散到各個(gè)服務(wù)器中。 為充分利用不斷增長的處理器核數(shù)量，需要程序員在編寫并行算法時(shí)發(fā)揮更大的作用，以便各個(gè)核能相互協(xié)作。目前的編程語言可采用類似消息傳遞接口(MPI)這樣的框架，但使用該方法需要占用大量設(shè)計(jì)時(shí)間。該方法可以升級(jí)，雖然有時(shí)并不是必需的，但當(dāng)系統(tǒng)設(shè)計(jì)做得不好的時(shí)候，程序員大多希望升級(jí)該方法。這也是人們對并行編程語言的興趣日益增長的原因之一。 帶MPI的高級(jí)單線程語言(例如C語言)和并行編程理論之間的主要區(qū)別是，并行編程理論通常假設(shè)存在隱式并行執(zhí)行。在工具包諱OD黽誘飫嚶镅雜行┪憊紓儼⒐刈⑺嗆問閉嬲鹱饔檬侵檔玫摹?br /> 諸如美國國家儀器(NI)的LabVIEW、MatLab的Simulink以及對象管理組織(Object Management Group)的UML(統(tǒng)一建模語言)等圖形編程語言和環(huán)境往往會(huì)針對新手和專家開發(fā)不同的設(shè)計(jì)。新手可從降低了復(fù)雜MOD的封裝中受益，而專家則獲得一種以任何人都能明白的方式表述復(fù)雜算法的途徑。任何使用過IAR Systems的visualState的人都了解，與內(nèi)嵌的C代碼相比，采用圖形化狀態(tài)圖做開發(fā)是多么容易。 這些面向基于文本的程序員的圖形編程環(huán)境已取得穩(wěn)步進(jìn)展。程序開發(fā)者也許仍然會(huì)更偏愛文本編程方法或圖形編程方法，但將兩者嚴(yán)格劃分(all-or-nothing)的方法似乎已過時(shí)了。 UML和C語言不再?zèng)芪挤置?許多UML 2.0產(chǎn)品已經(jīng)能夠針對Ada、C、C  和Java等語言從UML(統(tǒng)一建模語言)模型中生成代碼。盡管這樣，通常還是希望C語言開發(fā)者能學(xué)會(huì)UML。雖然以前的代碼可以繼續(xù)使用，但開發(fā)者應(yīng)該將學(xué)習(xí)UML作為新的目標(biāo)。 在Telelogic的最新版(V7)Rhapsody中，對C語言的最新支持通過允許C語言開發(fā)者在建模的同時(shí)保留文件和目錄層次(開發(fā)者已將文件和目錄層次與Eclipse IDE(集成開發(fā)環(huán)境)等工具一道使用)而實(shí)現(xiàn)了突破。 這不僅是對現(xiàn)有資源文件的利用，而且可利用這些文件的關(guān)聯(lián)關(guān)系來展示并構(gòu)建圖形模型。Rhapsody的反向工程特MOD可掃描源文件并生成這些C語言類型的模型，從而使得啟動(dòng)模型幾乎不費(fèi)什么力氣。 更重要的是，Rhapsody具有可在Eclipse CDT(C/C  開發(fā)工具)和UML模型之間來回變換的能力。變換朝兩個(gè)方向進(jìn)行，這使得設(shè)計(jì)師可以完成高層次的UML設(shè)計(jì)并在代碼中反映該變換。同樣，隨著UML中的功能逐漸可用，添加到C源代碼中的新功能也將顯示出來。只需點(diǎn)幾下鼠標(biāo)就可在C源代碼和與之匹配的UML定義之間反復(fù)變換。 當(dāng)然，如果并沒有采用合適的代碼管理工具，變換可能會(huì)讓程序員和管理者暈頭轉(zhuǎn)向。這就是新的圖形差異化特MOD十分重要的原因。它以圖形化方式凸顯了UML模型中的變化。 V7版Rhapsody中的另一項(xiàng)新功能是對Mathworks的Simulink R2006b的支持。它在UML和Simulink的代碼之間提供了相似的鏈接，從而允許將等式和Simulink建模代碼整合到Rhapsody中。該整合可提供協(xié)同執(zhí)行的能力。 并行編程語言的挑戰(zhàn) 并行編程語言仍處于研究開發(fā)階段。Sun的Fortress解決了大量應(yīng)用和編程問題，但它基于有大量內(nèi)核且內(nèi)核間通訊良好或內(nèi)核間共享存儲(chǔ)器的系統(tǒng)。線程與基本代碼模塊同步。 并行編程語言面臨許多挑戰(zhàn)，包括技術(shù)問題以及針對社會(huì)問題的優(yōu)化。對于大多數(shù)編程人員來說，轉(zhuǎn)換編程語言是件很不尋常的事情，而學(xué)習(xí)一種新的編程語言一般需要投入大量的時(shí)間和精力。 并行編程語言沒有沿用傳統(tǒng)串行編程語義，因此默認(rèn)值是執(zhí)行并行操作，而不是串行操作。編譯器和運(yùn)行時(shí)間環(huán)境必須對并行操作進(jìn)行優(yōu)化，使編程人員免于處理這些零碎工作。還必須明確定義串行操作，因?yàn)檫@時(shí)串行操作屬于例外而不是常規(guī)操作。